<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>A Note on System Failure</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Getting Started with Berkeley DB Transaction Processing" />
    <link rel="up" href="introduction.html" title="Chapter 1. Introduction" />
    <link rel="prev" href="introduction.html" title="Chapter 1. Introduction" />
    <link rel="next" href="apireq.html" title="Application Requirements" />
  </head>
  <body>
    <div xmlns="" class="navheader">
      <div class="libver">
        <p>Library Version 11.2.5.3</p>
      </div>
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">A Note on System Failure</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="introduction.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 1. Introduction</th>
          <td width="20%" align="right"> <a accesskey="n" href="apireq.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="sysfailure"></a>A Note on System Failure</h2>
          </div>
        </div>
      </div>
      <p>
            From time to time this manual mentions that transactions
            protect your data against 'system or application failure.' This
            is true up to a certain extent. However, not all failures are
            created equal and no data protection mechanism can protect you
            against every conceivable way a computing system can find to
            die.
        </p>
      <p>
            Generally, when this book talks about protection against
            failures, it means that transactions offer protection against
            the likeliest culprits for system and application crashes. So
            long as your data modifications have been committed to disk,
            those modifications should persist even if your application or
            OS subsequently fails.  And, even if the application or OS
            fails in the middle of a transaction commit (or abort), the
            data on disk should be either in a consistent state, or there
            should be enough data available to bring your databases into a
            consistent state (via a recovery procedure, for example). You
            may, however, lose whatever data you were committing at the
            time of the failure, but your databases will be otherwise
            unaffected.
        </p>
      <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
        <h3 class="title">Note</h3>
        <p>
                    Be aware that many disks have a disk write cache and on
                    some systems it is enabled by default.  This means that
                    a transaction can have committed, and to your
                    application the data may appear to reside on disk, but
                    the data may in fact reside only in the write cache at
                    that time. This means that if the disk write cache is
                    enabled and there is no battery backup for it, data can
                    be lost after an OS crash even when maximum durability
                    mode is in use.  For maximum durability, disable the
                    disk write cache or use a disk write cache with a
                    battery backup.
                </p>
      </div>
      <p>
            Of course, if your <span class="emphasis"><em>disk</em></span> fails, then the transactional benefits described in this book
            are only as good as the backups you have taken. 


            <span>
                By spreading your data and log files across separate disks,
                you can minimize the risk of data loss due to a disk
                failure, but even in this case it is possible to conjure a
                scenario where even this protection is insufficient (a fire
                in the machine room, for example) and you must go to your
                backups for protection.
            </span>
        </p>
      <p>
            Finally, by following the programming examples shown in this book, you can write your code so as to protect
            your data in the event that your code crashes. However, no programming API can protect you against logic
            failures in your own code; transactions cannot protect you from simply writing the wrong thing to your
            databases.
        </p>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="introduction.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="introduction.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="apireq.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Chapter 1. Introduction </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> Application Requirements</td>
        </tr>
      </table>
    </div>
  </body>
</html>
